There are numerous software programs and hardware devices currently available which allow asynchronous serial communications to be performed. A typical asynchronous communications application on a host computer consists of two functional entities: an Interrupt Service Routine (ISR), which is activated each time an interrupt is received from the serial port, and the application, which takes the characters received from the ISR and performs the requested operation.
The receiving of a character by the host computer typically goes through the following process. The character is generated by a remote transmitter, such as the receiving section of a modem, sent to a serial communications card, converted from a serial data format stream into a parallel data format character, and placed in a serial communications card buffer. The serial card then signals the host computer, with an interrupt, that a character is ready to be read from the serial card. The host computer has a maximum time of (1/character rate) to read this character from the serial card buffer before the serial card will receive another character and place this character in the buffer. For example, if each serial character requires 10 bits, including start and stop bits, then at 9600 bits per second (bps) or 960 characters/second, the host computer has (1/960) seconds (1.04 milliseconds) to read the character before it is lost. If the host computer does not read this character in time the character will be overwritten in the serial card buffer by the next character, and will be considered to have been "dropped." At higher data rates, the time constraints become more severe: at 19200 bps, the host has 0.52 milliseconds to read the character; at 38400 bps, the time drops to 0.26 milliseconds.
The host computer, upon receiving the interrupt, must stop whatever else it is doing and immediately read the character from the serial card. This is done by executing the serial card ISR. The ISR has a number of tasks to perform. Typically, it will first disable interrupts to prevent another interrupt from preempting the ISR. The ISR must then query the serial card to determine what caused the interrupt. Once it is determined that an incoming character has caused the interrupt, the host must verify that neither a parity error nor an overrun error was detected by the serial card, read the character from the serial card (thus clearing the interrupt), and place the character in a Random Access Memory (RAM) buffer for the application to process later. If the RAM buffer is approaching a full level the ISR may signal the remote computer to stop sending data. Additionally, the ISR may reenable the interrupts so that other devices can be serviced by their own ISRs.
Hardware devices employed for asynchronous serial communications typically contain a universal asynchronous receiver transmitter (UART), such as the 8250, 16450, and 16550A manufactured by National Semiconductor, Santa Clara, Calif. Software programs are generally designed to support a particular type of UART. The 16550A UART has a 16 byte buffer which eliminates the need for immediate attention to an interrupt generated by the UART. However, the host computer must service the UART at a sufficient rate to prevent the buffer from filling up or data will be lost.
The typical method employed for preventing data loss is to use data flow control: the software program signals the remote transmitter to halt the output of data until the host computer catches up with the data stored in the buffer. Typically, data flow control drives either the DTR (Data Terminal Ready) or the RTS (Request To Send) line of the serial card to a "not ready" status to halt the flow of serial data from the remote transmitter. Also, several data transfer protocols provide flow control via ASCII commands such as XON or XOFF.
A problem with this method exists because an application running on a computer with a long latency time, such as a multitasking system, may be slow in signalling the remote transmitter. Also the remote transmitter may send one or more characters before responding to the signal. The result is that the overall response time is too slow to halt the flow before data are lost. Also, some applications may not support flow control.
Therefore, there is a need for a serial data flow control method which signals the remote transmitter to halt the flow of a data in a timely manner such that data loss is prevented.
There is also a need for a method and apparatus which automatically controls the serial data flow without the intervention or knowledge of the application.